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(54) Method and system for a unicast endpoint client to access a muKicasl internet protocol (ip) 
session 



(57) Unicast endpoint clients (110. 111, 115) on an 
IP Unicast network (107. 108) are provided access to 
Multicast sessions on an IP MUticasl network (101) 
through a Multicast-Unicasl gateway server (120. 121). 
Tlie server obtains information about sessions on the 
Multicast niBtwork and makes such Information avallatile 
to a Unicasl client on the Unicast network upon request 
by the dienL Upon beirig presented with a list describ- 
ing the subject matter of each session, the user at the 
Unicast client selects the session to which he or she 
wants to join, whrch causes the Multicast-Unlcast server 
to join the appropriate session on behalf of the request- 
ing client for each media type in which the joining client 
wants to be a participant. The server then sets a bi- 
directional Unicast User Datagram Protocol (UDP) 

FIG, 1 



stream between itself arid the client. All packets then 
received by the server from the Unicast client are 
address-translated to the appropriate Multicast session 
address. In addition, ail packets received by the server 
on the Multicast session address are address-trans- 
lated and sent to the Unicast client The Unicast client is 
then able to participate in the Multicast session as both 
a sender and a receiver of packets to and from other 
Unicast and Multicast clients which are active during the 
session. Further, the Unicast client is capable of creat- 
ing a new session, recording a session in the networti 
for later retrieval and playback, and creating and 
accessing low kjandwidth versions of existing sessiorts. 




1 



EP0 902 569A1 



2 



Description 
Technical Field 

[0001] Thte invention relates to data oonrmjnicatk)^ s 
and more particutarly, to providing a Unicast endpoint 
client on a Unload network with the ability to access a 
Multicast session on an Multicast network. 

Background of the Invention ro 

[0002] In conventional packet, franne or cell based 
systems there are typically two nxxles of comnwntea- 
tion: point-to-point (also known as Unicast) arid point-to- 
muftipoint (also known as MuHkast). Multicast is 
addresses typically differ from Unk^^st addresses in that 
they refer to an intermediate abstractkni known as a 
groi^ All senders address their transmitted infomriatk)n 
to this group and all receivers are luned" to '*listen" to 
that address to receive the infomiation transmitted to 20 
that group by the senders. The senders of information 
are thus effectively de-coi^ed from the set d receivers. 
Senders do not r>eed to know wfK> the receivers are • 
they sinply transmit packets addressed to the group 
Similarly, receivers do not need to know who the send- 2S 
ers are - they simply send a request to the network 
(routers) to join a specif ic groi^ of interest 
[0003] Multimedia distribution and conferencing/col- 
laboration systems are advantageously and efficientiy 
supported by Multicaist communication methods. As will 30 
be used herein, a specific Multicast communication is 
refened to as a session. In the prior art, it is not possible 
for Unicast endpoints to access Multicast sessions, due 
to the differences in addressing modes and receiving 
nrodes. This disadvantageously limits the ability of a 3S 
user at a Unicast endpoint client to participate in ses- 
sions in which they have interest and in which they 
coukJ be an active participant 

Summary of the Invention 40 

[0004] In accordance with the present invention, Uni- 
cast endpoint clients are enabled to access Multicast 
sessions. Furthermore, in accondiance with the present 
inventions, Unicast endpoint clients are enabled to 45 
request network-based recording systenns perform 
recordings of the Multicast session on behalf of clients. 
Even furthermore, in addition to LAN attached end- 
points, analog diai-up (e.g.. 28.8 kbps) as well as ISDN 
Unicast endpoints are enabled to access appropriately so 
bandwklth-reduced versions of nominally high band- 
width sessions. 

[0005] Inter-connectivity between a Unicast client con- 
nected to a Unicast network and one or more Multicast 
clients connected to a Multicast network is effected ss 
through a Multicasl-Unicast Sender (MUS), in accord- 
ance vnth the present invention. Such a server obtains 
infomiation about sessions on the Multicast network 



and makes such information availaUelo the Unicast d- 
ent on the Unicast networi< ifx)n request by the cf erit 
Upon being presented wrtti a list desi^ng the subject 
matter of each sesskxt, tiie user at ttie Unk:ast dient 
selects the sessk>n to whteh he or she wants to Join, 
which causes the Multicast-Unkast server to join the 
appropriate session on behalf of the requesting client 
for each media type for whk:h the joining client wants to 
be a participant. The server tiien sets a bi-directk)nal 
Unicast User Datagram Protocol (UDP) stream 
behween itself and the client All packets tiien received 
by the server from the Unicast client are address-trans- 
lated to the appropriate Multicast sesskxi address. In 
addition, al packets received by tiie server on ttie Multi- 
cast session address are address-translated and sent 
to ttie Unk^ast cfient The Unicast client is ttien able to 
participate in the Multicast sessk>n as tx)tti a sender 
and a receiver of packets to and from ottier Unkast and 
Multicast clients which are active during the sessk>n. 
Further, such a Unicast client, if auttienticated to do so, 
is capable of creating a new session, and of recording a 
sesskHi in the networi^ for later retrieval and playback. 
Furttiermore, transcoding and rate adapting gateways 
are deployed wrttiin ttie Multicast networic that map 
existing sessions into low bandvtndtti versions. If the 
Unicast client is a dial-up user connected to ttie Unicast 
network over analog or ISDN ^cilities, ttiese rate-con- 
trolled sessions can then be accessed by ttie dial-up 
users. 

Brief Description of the Drawings 
[0006] 

FIG. 1 is a block diagram showing Unicast clients 
connected on a Unicast Internet Protocol (IP) net- 
woric accessing an IP Multicast networic ttirough 
Multicast-Unicast Servers (MUS's); 
FIQ 2 is a block diagram of a MUS; 
FIG. 3 shows the software components of a client 
terminal ttiat enable the client to access a Multkast 
session; 

FIG. 4 is a flowchart detailing the steps associated 
with a Unicast client joining a Multicast session on 
the Multicast network; 

FIG. 5 is a f kwchart detailing the steps of a Unrcast 
client creating a Multicast session; 
FIG. 6 is a flowchart detailing tiie steps of a Unicast 
client recording a Multicast session; and 
FIGS. 7A and 7B togettier detail ttie steps of a Uni- 
cast client rate-adapHng/transcoding a Muttrcast 
session. 

Detailed Description 

[0007] Witt! reference to FIG. 1 , an IP Multicast net- 
work 1 01 is shown including, as way of illustration, three 
interconnected Multicast Routers (MR) 102-1. 102-2, 
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and 102-3. A well known cun;ently In place IP MiKicast 
network is the so-caHed MBONE (Multicast Baddxxie). 
wtiich Is a piMic shared IP Multicast network spanning 
many countries and covering thousands of IP subHfiel- 
worte. In addition to the MBONE, numerous private 
Intranets also use Multicast IP for intra-corporate Qonrv 
munications. A plurality of multimedia client temninais 
are connected to IP Multicast network 101. for example 
the MBONE. For way of illustration only, in FIQ. 1 two 
client terminals 103 and 104 are shown connected to 
network 101 through respective Local Area Networks 
(LANs) 105 and 106. respectively. Each LAN is con- 
nected through a customer premises router (not shown) 
over, for example, a T1 line» Frame Relay (FR), ATM. or 
an X.25 connection. Iri accordance with Multicast conv 
munication. a sender of informatk>n of a particular 
media type transmits packets of information to a partic- 
ular address, which are then automatically distributed to 
each of the members of a group that have requested to 
receive from that address. Advantageously, the network 
performs the replication, functions necessary so that 
each receiver client of the group can receive the pack- 
ets transrrvtted to the address bf a sender or senders. 
[0008] In accordance with the present invention. Uni- 
cast client terrr^nals connected to a Unicast IP network 
is capable of joining in arxi partk;pating with a Multicast 
session on an IP Multicast network. FIG. 1 shows two 
Unicast IP networks 107 and 108. Illustrative Unicast 
client terrrunats 1 10. and 111 are connected to network 

107 tiirough conventional Unicast Routers (URs) 112 
and 113, respectively Unicast client terminal 1 1 5 is con- 
nected to UR 116 within network 108. UR 116 in turn is 
shown connected to another UR. UR 117 for exanrple, 
which in tum is connected to U R 1 1 8. Networks 1 07 and 

1 08 are shown as being interconnected through UR 11 2 
and 118, thus enabling Unicast IP communication 
between a client terminal connected to Unicast IP net- 
work 107and a client terminal connected to Unicast IP 
network 108. The Unicast client terrranals 1 10. 1 1 1 and 
115, for example, can t>e connected to networks 107 or 
108 pver a Plain Old Telephone Service (POTS) dial-up 
connection, an ISDN connection or an Asynchronous 
Digital Sutsscriber Loop (ADSL) connection, each to a 
Local Exchange Carrier (LEC) (not shown) and from 
thereto an Internet Service Provider (ISP) (not shown), 
which in turn is connected to the Unicast IP network 
through a Unicast Router. Alternatively, a client terminal 
can be connected to an ISP through a cable modem 
over cable fadlrties through a cable TV provider. Even 
further, the Unicast client terminal couki be connected 
to a LAN and to a customer premises router to a UR 
over, for example, a Wide Area Network (WAN), T1 fadt- 
ities, Frame Relay. ATM. or X.25. In accordance with 
this invention. Unk^ast client terminals 1 10. 1 1 1 , 1 1 5. for 
example, on Unicast IP networks 107 and 108. can par- 
tidpate in a Multicast IP session on IP MuKcast network 
101. Specifically, such functionality is enabled ttirough 
Multicast-Unicast Servers (MUS*s). such as MUS 120 in 



network 107 ^ ^MS 121 in network 108. which each 
interconnect their respective Unicast IP networks 107 
and 108, with the IP Multicast Network 101 : 
[0009] The Multicast-Unicast Servers 120 and 121 

5 function as gateways that enable those UDicast'Con- 
- necteddients on their respective Unk:ast IP networks to 
access IP Muttk:ast network 101. Spedfically, each 
MUS through interaction with dient software on the Uni- 
cast client on the Unicast IP network enables sudi dient 

10 to jdn a group on tt)e IP Multicast network by providing 
information relating to what 5essk)ns are in progress or 
scheduled on network 101. The MUS then receives and 
sends data on those groips within a session selected 
by dient on behalf of the dient Thus, the MUS functions 

15 to convert the address of the Multicast IP packets of a 
requested-for group to the Unicast IP end^xM address 
of the requesting dient Furthernme. the MUS func- 
tions to transmit packets it receives from the Unicast 
erxlpoint dient to a list of any other Unicast endpoint 

20 receivers for the requested-fpr Multicast group on the 
same Unicast IP network or an interconnected Unicast 
IP network (107 or 108), as well as to the Multicast 
group address itself on the IP MuKca^ network 101 to 
enable the Multicast endpoints, 103 and 104. for ieicanv 

25 pie. connected on that network to receive packets origi- 
nating from ttie Unicast dient 
[001 0] FIGS. 2 and 3 are block diagrams of an MUS 
201 and a client terminal 301. respectively, showing 
iheir functions that enable them to operate in adodrd- 

30 ance with the present invention. In FIG. -2 a Session 
Description Protocol (SDP) listener process 202 cou- 
pled to tine IP Multicast network 101 listens for session 
announcements transmitted on Multicast network 101. 
Such directory announcements are repeatedly sent 

35 over the IP Multicast network 101. These "advertised" 
sessions are received by ttie SDP/SAP advertised proc- 
ess 203 and stored in a sessions database 204. Other 
sessipns that are not announced and tiius hot received 
by the SDP listener process 202, are entered by a sys- 

40 tem administrator through a static sessions process 205 
and also stored In sessions database 204. An example 
of the latter might be a weather channel that Is always 
present oh a predetermined socket and is not repeat- 
edly announced over tiie IP Multicast network 101 . 

45 [00111 An HTTP server 206 can read the sessions 
database 204 so that when a client connects to the 
server, the dient is able to receive a listing of those Mul- 
ticast sessions presentiy on the IP Multicast network 
101. When the client connects to the server 206, tiie 

so server executes a CQl (Common Gateway Interface) 
scripts 207 within the HTTP server 206 on behalf of the 
dient to present the information pertaining to \he ses- 
sions to the client. Such information is presented, back 
to the client 301 (FIG. 3) through its web browser pro- 

55 gram 302 (in FIG. 3). The dient initiates a request to join 
a session by sdeding a URL on an HTML web page 
presented to It by HTTP server 206. A message is thus 
sent from the dient 301 by web broker 302. which 
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when received by server HTTP 206 causes it to invoke 
certain actior^ Specifically, HTTP server 206 sends a 
response back to the client comprising a control nies- 
sage containing infonnation indicating what tool needs 
to be used in order to join the selected session. Such 5 
tools are wen known in the art and may include. Ibr 
example, the Visual Audio Tool (VAT), the Visual Confer- 
ence Tool (VIC), or the Internet Protocol Television Tool 
(IPTV). Furthemiore, the message indicates where the 
tools should be connected. I.e., specif teally, to whteh ^ 
socket on the MUS the tool should be connected. On 
the client side, the client 301 then launches from launch 
program 303 the specified tool from tool program 304 to 
the indicated sockets on the MUS 201 . CGI scripts pro- 
gram 207 then initiates the translation/ljackel-fbnward- 75 
ing server 208 within MUS 201 to join the requested 
Multicast group or groups (one group per selected 
media type) associated with the selected session. CGI 
scripts 207 that initiated such join action to take place 
then adds that dienfs Unicast address to a list of receiv- 20 
ers for the requested Multicast group or groups. Sender 
208 then fbnwards Multicast packets received from the 
client to the list of receivers for each joined group and 
translates the Multicast address of packets received 
from the joined group to the Unicast address of the join- 25 
ing client 

[0012] The steps associated with a client joining a 
session are detailed with reference to the fJowchart in 
FIG. 4. At step 401. the SDP listener process accumu- 
lates IP Multicast network 101 directory announce- so 
ments into database 204. The database is filtered and 
converted into a standard HTML page, where each URL 
points to information pertaining to each Multicast ses- 
sion in the filtered database. At step 402, the HTTP 
sender 206 listens for requests lor Multica^ ses- 35 
sions/URLs on the HTML page which contains a list of 
URLs describing ti^e sessions. At step 403, a request is 
received froni a dienl for a copy of the page containing 
the Multicast sessions. At step 404, tiie HTTP sender 
206 sends a message back to the client requesting the 40 
user enter a login id and a password for authentication 
purposes. If the user is successfully authenticated at 
step 405, at step 406, server 206 returns a page to the 
client containing a list of sessions. When, at step 407, 
the user of the client browses the page and requests a 45 
session indicated by a URL, at step 408. server 206 
returns a page containing details of the session and but- 
tons enabling the client to request ttie session to start 
as well as other functions to be described later herein. 
At step 409, the client starts a selected session (or spe- so 
cific media in the session) by ^Dressing" a button on the 
HTML page. The server 206 then launches a control 
script 207. At step 410, tfie control script 207 sends a 
response to the client containing information about 
which multimedia tool to launch, and what UDP sockets 55 
(the Unicast IP address on ttie MUS and associated 
PK)rts) to listen to and to send information to correspond- 
ing to the requested group. It can be assumed that at 



least one socket is used. A second socket may be used 
to send control^tus information from each member of 
the Multicast group. At step 41 1 . the same control scr^ 
207 of server 206 cause$ the Multicast-to Unicast gate^ 
way to join the requested-for Multicast group find 
tfie requesting client to the list of receivers tor the 
requested for Multteast group. For each requesting cf-^ 
ent, sender 206 also converts the address of the Multi- 
cast IP packets of the requested-for group to the 
Unicast IP address of the requesting client and sends 
the Unicast IP packets to the requesting dienl using the 
well-known User Datagranri Protocol (UDP). Server 206 
also transmits any packets it receives from the client to 
any other Unicast client on that Multicast groups as well 
as to the Multicast group address itself on the IP MuW* 
cast networi< 101. At step 412, when the client exits 
from the multimedia tod. server 206 detects tiiat status 
messages from the dient are no bnger being sent and 
removes the dient from the list of destinations for the 
partfcular Multicast group. . 
[001 3] The steps assodated with a dient creating a 
hew session are detaned in FK3. 5. At step 501 , as pre- 
viously described In connection witti the steps in FIGL 4 
assodated with a dient jdning a sessioa the SDP lis- 
tener process 202 accumulates IP Multicast network 
101 directory announcements into database 204. The 
database is filtered and converted into a standard 
HTML page, where each URL points to information per- 
taining to each Multicast sessk>n in ttie Jittered data- 
base At step 502, the HTTP sender 206 listens for 
requests for Multicast sessions/URLs on tiie HTML 
page which contains a list of URLs desaibing tiie ses- 
sions. When a user of a dient requests a copy of the 
page containing the Multicast sessions at step 503, the 
server 206, at step 504, sends a message back to the 
dient requesting a login id and password tor authentk;a- 
tipn purposes. If authentication is successful at step 
505, at step 506, server 206 returns a page to the dient 
corrtaining a list of sesstons. When the user browses 
that page and requests a specific URL., server 206, at 
step 507. returns a page containing details of the ses- 
sion and buttons enabling the dient to request a sesskxi 
to start, to create a new session, to edit or delete an 
existing session, and to record ttie current session, tiie 
later functionality to be descrtoed hereinafter. When, at 
step 508, tfie user "presses" a button to create a new 
session, at step 509, server 206 returns a form to the 
dient requesting the client to enter a \oq\t\ id and pass- 
word appropriate for creating a new session, wvhich may 
or may not be the same as the login id and password 
associated witfi the initial autiientication process. If, at 
step 510, the dient is authenticated for session aea- 
tion, sen/er 206 returns at step 51 1 a form to the dient 
with fields to be filled in by the user for the session 
name, session desaiption, a URL address for more 
detailed or related information, a field to set the Multi- 
cast packet Time to Live value (TTL), selection boxes for 
various media tods, and associated codirig formats, 
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Multicast addresses and ports to use, the name and 
phone number of a responsMe person, and the dura- 
tion of the session announcement. When the userfBIs in 
the fields and selects a create buttori, the fllednn fonm 
is returned to the server 20& Server 206 checks that 
certain key fields are connect and filled in. If not, an error 
message is returned to the client; otherwise server 206 
stores the data in a file that is indexied to the bgin kl 
used to access the form. The data, at step 512, Is then 
made available to a Session Announcement Protocol 
(SAP) process 210 on MUS 201. At step 513, the SAP 
process 210 periodically announces the 8essk>n onto a 
well-known Multicast IP address ^nd port reserved for 
such announcenr>ents for a period of time equal to the 
duration fiekJ as entered In the form. When tNs time 
period expires, the SAP process 210 ce^es to 
announce the &essk)n. 

[0014] A Unicast endpoint can also, in aooondance 
with the present invenboo. /equesl ttiat a sessfon l>e 
rec<>rded for later rebroadcast or retrieval oh dehnand. 
To effect such recoriciing. m FIG. i. a recorder 125 is 
connected via LAN 126 to the IP Multicast network 101. 
The flowchart in FIG. 6 details the steps associated with 
a user at a client terminal requesting that a session be 
recorded. As described previously, the client must be 
given a login id and password to enable access to the 
HTTP sender 206 which has a list of the IP Multfcast 
sessions. At step 601. the SDP listener process 202 
accumulates IP Multicast network 101 directory 
announcements into sessions database 204. The data- 
base is filtered and converted into a staridard HTML 
page, where each URL points to information pertaining 
to each Multicast session in the filtered datat>ase. At 
step 602, server 206 listens for requests for Multicast 
sessions/URLs on the HTML page which contains a list 
of URLs describing the sessions. When, at step 603. a 
user requests a copy of the page containing the Multi- 
cast sessions, at step 604. server 206 sends a message 
t>ack to the client requesting his or her login id and pass- 
word for authentication purposes. If. at step 605. 
authentication is successful, at step 606. server 206 
returns a page to the client containing a list of sessions. 
When a user browses that page and requests a URL. 
server 206. at step 607. returns a page containing 
details of the session, and buttons enabling the client to 
request a session, to start the existing session, to cre- 
ate a new session, to edit or delete an existing session, 
or to record the current session. At step 608, the user 
"presses" a button to record a session and, at step 609, 
server 206 returns a form to the client requesting the 
user to enter a login id and password for recording pur- 
poses, which may or may not be the same as the login 
id and password used in a pre^/ious step. If. at step 61 0. 
the client is authenticated for session recording, sender 
206 returns a form to the client with fields to be filled in 
or options to be selected. The form contains selection 
boxes for the various media of the session, and start 
and stop date and time fields, as well as a start button to 



"push" when the form is complete. When the user fills in 
the fields and selects the start form, the filled-in form 
returned to server 206. Server 206 checks that certain 
key fiekls are conect and filled In. H not. an error meis- 

5 sage is returned to the diiant: otherwise the server 
stores the data in a file that is indexed to the fogin d 
used to access the forra At step 6.1 1 . server 206 serxls 
a message to the recording server 125 to start the 
recording at the specified date and time. The recording 

10 server 125. at step 612, then records the session at the 
appropriate time using a well-known program for read* 
ing IP MuHicast packets in the RTP formal At step 613. 
the stored sessfon is retrieved on-demand by the user. 
[0015] To support dial-up Unicast endpoint users, 

15 prior art transcoding and rate adapting gateways, such 
as transcoder/adapter 127 in FliGL 1, are depfoyed 
within IP Multicast network 101. As shown in FICL 1. 
transcoder/rate adapter gatew^ 127 is connected via 
LAN 128 to the IP Multicast network 101. Altemativety, 

20 transcoder/rate adapter gateway 127 may be co-resi- 
dent with either MUS 120 or 121. The gateway maps 
existing high bandwidth sessions into loW bandwidth 
versions of |he sairie session surteible for 2aS kbps 
nrxxJems or ISDN adapters by usin^ frame discar^ding 

2S algorithms. Announcements alxHJt these rate-contrd^ 
sessions are then placed in the datat>ase of IP Multfoast 
network 101 sessions. ' . 

[001 6] An altemative mebh^i^ for iiiVokirig the 
transcoding/rate adapting gatew^ (^ld' be b^s^J bh 

30 user/Client action. The Steps a^sodaited with a diient 
requesting that a session be automatically trans- 
coded/rate adapted are detailed in FIGS. 7A and 7B. As 
descrit>ed previously, the user of the client must be 
given a login kJ and a password to enable access to 

35 HTTP server 206. As descn*bed previously, at step 701 , 
the SDP listener process 202 accumulates IP Multicast 
network 101 directory announcements into database 
204. The database is filtered and converted into a 
standard HTML page, where each URL points to infor- 

40 mation pertaining to each Multicast session the fStered 
database. It is assumed that a required bandwidth 
parameter and rnaximum packet loss parameter are 
associated with each session. For sessfons using a 
form as previously described, this is accomplished by 

45 the use of additional fiekls corresponcfing to these 
parameters in the "new session" form described herein- 
above. At step 702, HTTP server 206 listens for 
requests tor Multicast sessior^RLs on the HTML 
page containing a list of URLS describing the sessions. 

50 When, at step 703, a request is received from a dient for 
a copy of the page containing the Multicast sessions, at 
step 704, server 206 sends a message back to the cli- 
ent requesting a login kJ and password for authentica- 
tion purposes. H. at step 705. authentication is 

55 successful, at step 706. server 206 retums a page to 
the client containing a list of sessions. When after the 
user browses the page, and at step 707, selects a ses- 
sion and group(s) within a sessfon, server 206, at step 
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708, returns a page containing details of the session 
and txjttons enabGng the client to request a session to 
start, to a^ate a new session, to edit or delete an exit- 
ing session, or to record the current session. At step 

709. the i^er pushes a txjtlon to requ^ the session or 5 
specific media In the session to start In response 
thereta at step 710, server 206 launches a control 
script which sends a series of test packets to the client 

At step 711 , the cfient echoes these same packets back 
to the server 206. At step 712. the sen^ computes an 10 
estimate of the availatsle bandwidth and packet loss 
along the path between the sender and the client by 
comparing the transmitted test packets with the 
received test packets. If , at decision step 713, the per- 
formance requirements of the session exceed that of 13 
the path, at step 714, rate-adaptation or transcoding 
heeded. If not. the process continues as previously 
described for a client joining an existing session. If rate 
adaptation or transcocfing is needed, at step 715, one 
out of plurality of lower rate encodings is selected based 20 
on the measured characteristics of the path. It is to be 
assumed that a finite set of rate adapted sessions are 
allowed by the sender 206. As an exarnple, if the origihal 
session was 128 kbps, rate adaptation to 56 Msps, 28.8 
kbps and 20 kbps may be allowed. At step 71 6, HTTP 25 
server 206 sends a message to the transcoding/rate 
adapting gateway 127 indicating which Multicasft group 
is to be joined, to what bandwkith the miadia-type shpukJ 
be rate-adapted, what (if any) alternative coding needs 
to applied, and what new Multicast address and port $0 
number the transcoded session should use. At step 

717, a determination is made whether that group has 
already been rate-adapted/lranscoded. If yes, at step 

718, the Multicast address and port number corre- 
sponding to the already rate-adapted/transcoded group 35 
is used and the process proceeds to step 719. If no, at 
step 720, the transcoder/rate adapter gateway 127 is 
Invoked to transoode the session with appropriate barxl- 
width parameters and to re-Multicast the resulting 
lower-bandwidth sessk>n using a different Multicast 40 
address and port number. At step 719, the server 206 
sends a message to the client containing information 
about which multimedia tool to launch, and what UDP 
sockets (the Unicast IP address on the MUS and asso- 
ciated ports) to listen to and to send information to cor* 45 
responding to the requested session. At step 721, the 
control-script causes the MUS gateway to join the. 
requested Multicast group and add the requesting client 

to the list of receivers for requested Multicast group. For 
each requesting client the server converts the address so 
of the Multicast IP packets of the requested-for group to 
the Unicast IP address of the requesting dient, and 
sends the Unicast IP packets to the requesting client 
using the well-known User Datagram Protocol. The 
server also transmits any packets it receives from the 55 
client to the list of receivers for that Multicast group, as 
well as to the Multicast group address itself. At step 722, 
when the client exits the multimedia tod, the HTTP 



server 206 detects that status messages from the client 
are no kmger being sent and renxsves the dierrt froni 
the list of destinations for the particular Multicast^ group. 
[0017] The system described hereinaboye is highly 
scaleable in that the MUS and other servers may be dis- 
tributed throughout the Multicast-enabled portion of the 
network. If the number of such endpoints is Bkely to be 
large, for effidency. it is preferred ttiat the servers be 
located dose to the Unicast dient endpoints. For small 
oonferendng group, the tocation or dtstritxitkMi of the 
MUS*s ts not inportanL Advantageously, the present 
invention enables any IP Multicast-based service to be 
gradually introduced and rolled out on a small scale 
before all dients are enabled for IP Mufticast As dients 
become IP Multicast enabled, there could be a transi- 
tion to a hybrid IP Multicast nrxxJe of operation where 
some cfients are IP Multicast connected and others are 
not 

[0018] Although described in connection with Unicast 
IP eridpoints connecting to an IP Multicast network 101 
such as the MBONE, tfie present invention could jbe 
empbyed with any IP Multicast network Further the 
present invention coukJ be employed with any Multicast 
network and Unicast network that operate in a similar 
fasNon to IP Multicast and Unicast networks. 
[0019] The above-described embodimerits are Blus- 
trative of the prindples of the present invention. Other 
embodiments coM be devised by those skilled in the 
art without departing from the spirit and scope of the 
present invention. 

[0020] Where technical features mentioned in any 
daim are followed by reference signs, those reference 
signs have been induded for the sole purpose of 
increasing the intelligibSity of the claims and accordingly 
such reference signs do not have any limrting ^ect on 
the scope of each element identified by way of example - 
by such reference signs. 

Qalms 

1 . A method of providhg access to a Multicast session 
on a Multicast network to a Uriicast cHent on a Uni- 
cast network comprising: 

accumulating at a gateway server interconnect- 
ing the Multicast network and the Unicast net- 
work directory infonnation relating to Multicast 
sessions on tiie Multicast network; 
supplying the Unicast dient with the directory 
informatfon accumulated by the gateway 
server; 

receiving at the gateway server from the Uni- 
cast dient a request to join a selected session 
chosen from the directory information; 
joining the requested-for Multicast session at 
the gateway server on behalf of the Unicast ci- 
ent; 

converting at the gateway server an address of 
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Multicast packets received on a Multicast 
address associated wHh the requested-tor ses- 
sion to a Unicast address of the Unicast client 
and sending the Mulficast packets received t>y 
the gateway server on the MuHk^ast address to 5 
the Unicast client; and . 
transmitfing packets received at the gateway 
server from the Unicast client to the Multfcast 
address associated with the requested-tor ses- 
sion. ^0 

2. The method of daim 1 wherein the request to join a 
Multicast sesston is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of said plurality of groups is 
having an associated Multicast address. 

3. Theme^odof daim 2 wherein each of said at least 
one group is assodated with a different media type. 

4. The method of daim 1 further conprising before 
supplying the Unk:ast dient with the cfirectory infor- 
mation, authenticatng the Unicast diefit 

5. The method of claim 4 wherein the authenticating 25 
comprises rec^ving at the gateway server a login 
kJentity and a passvvord from the Unicast diertt i 

6. The method of daim 1 wherein the Unicast and ^ 
Multicast networks are IP ^Internet ProtocoO Uni- 30 
cast and IP Multicast networks, respectivety. 

7. The method of daim 6 wherein pad^ets are trans- 
mitted between the gateway serva; and the Unicast 
ciient using the User Datagram Protocol. 35 

8. The method of daim 6 wherein the directory infor- 
mation comprises an HTML page having a plurality 
of URtjs each pointing to information assodated 
with a Multicast session on the IP Multicast net- 40 
work. 

9. The method of daim 6 wherein the IP Multicast net- 
work is the MBONE. 

45 

10. A method of creating a Multicast session on a Mul- 
ticast network by a Unicast client on a Unicast net- 
work comprising: 

accumulating at a gateway sender interconnect- so 
ing the Multicast network and the Unicast net- 
work directory information relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast drent with the directory 
information accumulated by the gateway ss 
server; 

receiving a request at the gateway server from 
the Unicast dient to aeate a Multicast session; 



receiving and storvig at the gateway server 
infonnatk>n about the Multcast session; and 
announdng the Multtoast sesskx) by the gate- 
way serviBT onto the Multicast network onto a 
predetemiined Multkast address for such 
announcements. 

11. The method of daim 10 wherein the Unteast and 
MUticast networks are IP (Internet Protocol) Uni- 
cast and IP Multicast networks, respectively. 

12. The method of daim 10 wherein the session is 
announced periocfically onto the Multk^ast network. 

IS. The method of 10 further comprising before supply- 
ing the Unicast dient with the directory infonnatkxi. 
authentk^ating the Unicast dient 

14. The method of daim 13 further comprising after 
receiving a request at the gateway server from the 
Unicast client to create a session, authenticating 
the Unicast dient to aeate a sesstoa 

15. A method of recording a Multicast session on a Mul- 
ticast networic by a Unicast client on a Unicast net- 
wori( comprising: 

accumulating at a gateway server interconnect- 
ing the Multicast netwcxk and the Unicast rtet- 
viork directory intonnation relating to Multicast 
sessions on the Multicast network; 
supplying the Unicast dient with the dir^ory 
information accumulated by the gateway 
server; 

receiving a request at the gateway server from 
the Unicast dient to record a selected Multicast 
session, chosen from the directory infbmnation; 
and 

sending a message containing informatk>n 
about the selected Multicast session from the 
gateway sender to a recording server con- 
nected to the Multicast network to record the 
selected sessbn. 

16. The method of daim 15 wherein the Unicast net- 
work and the Multicast network are IP (Internet Pro- 
tocol) Unicast and IP Multicast networks, 
respectively. 

17. The method of claim 15 further comprising receiv- 
ing at the gateway server from the Unicast dient 
intonnation afcx)ut the selected Multicast session 
induding when to start and stop recording. 

18. The method of daim 17 wherein the information 
received at the gateway sender from the Unicast di- 
ent further indudes an identification of spedfk: 
media to record of the seleded Multicast session. 
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19. The method of daim 15 ftirther comprising before 
supplying the Unicast dieirt with the directory ir^^ 
matipn, authenticating the Unicast dienl. 

20. The method of daim 19 further comprising after s 
receiving a request at the gateway server from the 
Unicast client to record a session, authenticating 
the Unicast cDent to record a session. 

21 . The method of claim 1 5 further comprising: io 

receiving a request at the gateway server from 
the Unicast client to access the recorded ses- 
sion; 

sending a message to the recorcfing server 75 
from the gateway server to the recording server 
to retrieve the recorded session; 
receiving the recorded session at the gateway 
server; and 

sending the recorded session from the gateway £0 
server to the Unicast cljeni 

22. A method of providing access to a Multicast session 
on a Multicast network to a Unicast dient on a Uni- 
cast network comprising- 25 

accumulating at a gateway server interconnect- 
ing the Multicast network arid the Unicast net- ' 
woric directory information rotating to Multicast 
sessions on the Multicast network, the direc- so 
tory information including for each session a 
Multicast address for the session and a 
required bandwidth of the session; 
supplying the Unicast client with the. directory 
information accumulated by the gateway 3S 
server; 

receiving at the gateway server from the Uni- 
cast dient a request to join a selected session 
chosen from the directory informatk>n; 
determinrig an estimate of the availat>le band- 4o 
width between the gateway server arxJ the Uni- 
cast cBent; 

if tile estimate of the availat)le bandwidth is less 
than the required bandwidth lor the selected 
session, selecting a coding rate lower tiian a 45 
cocfing rate associated with tiie selected ses- 
sion; 

sending a message from the gateway server to 
a transcoding server connected to the Multicast 
network to rate-adapt the coding rate assod- so 
ated vinth tiie selected session to the seleded 
lower cbcfing rate; 

receiving at the gateway server from the trans- 
coding server an indication of tiie Multicast 
address to which tiie rate-adapted selected ss 
session is being transmitted; 
joining tiie rate-adapted sessk>n on behalf of 
tiie Unicast dient at tiie gateway server on the 



indicated Multicast address to which ttie rate- 
adapted selected session is being transmitted; 
converting at the gateway server tiie address of 
the Multicast packets received on tiie Multicast 
address to which tiie rate-adapted selected 
sesskKi is being transmitted to a Unicast 
address of tiie Unicast dient and sending tiie 
Multicast packets received by tiie gateway 
server on ttiat Multicast address to tiie Uncast 
client and 

transmitting packets received at the gateway 
server from tiie Unicast dient to tiie Multicast 
address to whtoh tiie rate-adapted selected 
sesskMi Is transmitted. 

23. The method of claim 22 wherein the Unicast and 
Multicast netwod« are IP (Internet Protocol) Uni- 
cast networks and IP Multicast networi^ respec- 
tively. 

24. The method of daim 22 wherein the request to join 
a Multicast sesston is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of said plurality of gi^oups 
having an assodated Multicast address. 

25. The method of daim 24 wherein each of said plural- 
ity of groups is assodated witfi a different nried*^ 
type. 

26. The mettiod of daim 22 wherein determining an 
estnnate of the availat>le bandwidtii comprises: 

transmitting a series of test packets to tiie Uni- 
cast dient; 

receiving an echo of tiiese test-packets b^ck 

from tiie Unicast dient 

arKi 

comparing tiie transrriitted series of test-pack- 
ets witii the received echo of tiiese test pack- 
ets. 

27. A Multicast-Unicast server conprising: 

means for accumulating from a connected-to 
Multicast network directory infomnation relating 
to Multicast sessions on the Multicast network; 
means for receiving from a Unicast dient on a 
Unicast network connected to tiie server a 
request to join a Multicast session from among 
the sessions accumulated in the directory infor- 
mation; 

means for joining tiie requested-for Multicast 
session on behalf of the client; and 
means for converting tiie Multicast address of 
the Multicast packets on the requested-for Mul- 
ticast session to a Unicast address assodated 
with tiie Unicast dient and for sending ttie Mul- 
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ticast packets on the requested-for ^Mtlcast 
session to the Unicast client al that Unicast 
address, and for sending packets received from 
the Unicast client to the MuWcasl address 
associated with the selected sessioa 5 

28. The server of claim 27 wherein the Multicast net- 
work and the Unicast network the server is con- 
nected to are an IP (Internet Protocol) Multicast 
network and an IP Unicast network, respectively. 10 

29. The server of claim 28 wherein packets are trans- 
mitted between the sender and the. Unicast client 
using the User Datagram Protocol. 

IS 

30. The server 0I claim 27 wherein the request to join a 
Multicast session is a request to join at least one 
group of a plurality of groups associated with the 
Multicast session, each of pluraGty of groups having 

•an associated Multicast address. so 

31. The server of claim 30 wherein each of sakJ plural- 
ity of groups is associated with a different media, 
type. 

25 

32. The server of clairn 27 wherein the means for con- 
verting also sencfe packets received frbm the Uni- 
cast client to anottier Unicast client associated with 
the server and which said another client is also con- 
nected to the session. 30 
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